Mobile commerce offers convenience to users such that they can perform business transaction, anytime, anywhere. Though Wireless Application Protocol (WAP) has been around for several years, the market penetration of WAP enabled cell phones, and other such web enabled wireless devices still remains quite low. The most established technology in the space of mobile commerce today is Short Message Services (SMS) on mobile wireless devices. With SMS's high penetration and adoption rate in the market, it has been a prime target for mobile commerce usage.
Examples of SMS notification with commerce functions contemplated by the present invention include the following:
marketing driven message to user: e.g. discount information, promotion and other commerce campaign information;
notification for business events: e.g. order received confirmation, shipping confirmation; and,
notification for operational efficiency like payment due, or other deadline driven type reminders.
However, various intrinsic technical hurdles and limitations exist in SMS today, thus making its application and usage in commerce web application difficult and impractical.
There are a number of limitations to prior art technology and a requirement exists for the use of SMS messaging in business environments. A discussion of these limitations and requirements follow.
Limitations of Using SMS in Commerce Transactions
The absence of the concept of semantics in SMS make SMS usage in commerce application difficult. The difficulty lies in:                the encoding of the SMS message to accurately implement a given business purpose; and, the corresponding run time handling of the SMS message as the business purpose requires.Encoding Barriers        
SMS messages, by nature are typeless, stateless, sessionless and meaningless to data processing systems. Currently the main purpose of SMS messaging is person to person communication between mobile devices.
However, for SMS messages to be viable as means of business transactions, SMS cannot be just a casual exchange of two parties. Business transaction requirements include: trace ability, confirmation, and non-repudiation. It also has to be understood by any web application or other data processor that handles it. We collectively define these requirements as the semantics of SMS messaging.
For example:                A given set of business rules may require that a subset of SMS messages be confirmed on delivery for non-repudiation of transactions such as:        i. confirmed arrival        ii. recorded timestamp of arrival for non-repudiation        iii acknowledgement of reception of SMS messages        
It may also be a business requirement that a given set of SMS messages are to be regularly delivered based on a given schedule. Examples include:                i. monthly reminders of invoices        ii. scheduled promotions via SMS messages        
Broadcasting Type SMS messages may be required by businesses to reach multiple users without the need of checking or confirming message arrival. Examples include:                i. Store wide promotional broadcasts.                    In this case acknowledgement would likely not be required.                        
When a user wants to send in a SMS message to make a transaction, the intent of the user (e.g. to buy a given item) as encoded in the SMS message text has to be unambiguously understood by a web application or other application that handles the user's incoming SMS message.
Correctly encoding SMS messages to accurately represent business intent is a technically complex and difficult task and is highly prone to human error. Human errors in encoding are often very expensive and difficult to debug and correct. Business users want efficiency and reliability in using SMS to achieve their business objectives. They require sheltering from such technical complexity when using SMS messages in their business processes. Business users typically only want to focus on:                i. Determining the business intent of a given SMS message;        ii. Forming the correct wording of the message (without worrying about the different technical details of encoding); and,        iii. Being informed of error if the message sent does not meet the intent of that message classification.        
Business users who initiate these business transactions now face the significant technical challenge of manually encoding all of these SMS messages correctly so that they map accurately to the particular different business objectives that they set out to achieve.
Difficulty in Semantic Handling at Run Time
Apart from the manual, technical challenge in SMS message encoding, semantic handling at run time to meet business process requirements is also a major problem.
For example, a SMS message notifying a user of an outstanding payment typically requires the acknowledgement of the user, as stipulated by a business process that defines “a completed customer touch point”.
The lack of acknowledgement by the user upon receiving the SMS message in this case will be handled differently than other SMS message.
However, the concept of semantics and categorization does not presently exist in the space of SMS today.
The Absence of Syntax in SMS Messages Makes its Usage in Commerce Business Processes Difficult and Impractical
Lack of Mapping of SMS Text Stream to a Commerce Business Action
SMS messages are simple text messages without any encoding scheme. Thus, a simple plain text SMS message is unsuitable for commerce transactions for the following reasons in addition to the ones mentioned above:                i. Its not currently possible for a simple SMS message to indicate the type of commerce transaction to be carried out;        ii. Additional parameters required by a particular transaction cannot be encoded in a standard manner and hence, cannot be parsed by the backend commerce application;        iii. Additional details like user authentication and authorization can not be taken care of in a standard manner;        iv. Lack of state information means request-response model required by commerce transactions can not be applied to commerce SMS messages; and,        v. Free form composing of 160 characters as responses by human users makes the adoption impossible and impractical.        
The above problem creates a serious usability issue for SMS users (both human and web application) who need to respond to business messages originated from a Web Application or other data processing application.
Lack of Notation for Parameters Encoded as Part of the SMS Message
All inbound SMS messages carrying transaction information are required to be validated for data completeness and data validity. Not only that, users sending SMS messages to a given web application are required to encode enough information in the inbound SMS messages for proper authentication.
For example, using SMS in online auction requires that the backend web application used to communicate to bidders notify the subscribed bidders whenever an auction bidder has been outbid by someone else. Bidders, upon notification, should be given a mechanism to respond in order to raise their bids.
In this example, the SMS message is required to be sent in a non-repudiated manner so that the subscribed bidders can't deny receipt of auction override notices. Also such messages must be sent out via a high priority channel, if available, so that they can reach the bidders as soon as possible. In addition, the auction bidders are required to have a mechanism to call back the backend commerce application being used in the auction to submit a new bid using a standard SMS message template acceptable to the backend commerce application. These SMS messages must be parsed correctly by the backend commerce application in order for the backend web application to perform the appropriate semantics.
As an example, one of the required parameters in an auction scenario would be an SKU number for the identification of item under bid. Both back end server and bidder authentication is required for non-repudiation purposes.
The lack of syntax in SMS messaging makes application to the following business processes extremely difficult:                commerce process mapping;        user authentication;        parameter passing;        data validation.Technical Complexities in Encoding SMS Deter Business Users from Adopting its Usage        
The originators of business SMS messages are business users who have business needs to send business messages. Their prime concern is to focus on the business logistics of the message (like the timing of sending, to whom to send the message to etc.) and the message itself (like the choice of wordings etc.). They do not want to be (and typically cannot afford to be) burdened with the technology of the delivery medium. For example, the technical knowledge of how to send a SMS message is something that the business users do not want to deal with and expect to be handled for them. Transparency and user friendliness is important to a business user.
The Requirement of Confirmation in Commerce Usage
A key requirement of to use SMS in commerce is the need for confirmation from SMS message recipients. The following is a list of examples for such critical requirements in SMS usage in commerce:                Upon receiving a SMS notification from the commerce server, often the recipient needs to respond by sending an SMS message back to the commerce server. For example: the recipient may send an SMS message back to the commerce server to buy an item advertised by an SMS promotion message.        To fulfill the non-repudiation requirement, for example: all customer touch points need to be recorded.        Confirmation also requires the confirmation of user ID in an inbound message.The Requirement of Security in Commerce Usage        
Another key requirement for using SMS in commerce is the need for security in carrying out a business transaction. This requirement includes:                User ID authentication by a web application like WebSphere when a user initiates a transaction using SMS message        Web application authentication by the user so that the user knows for sure that the correct Web application is handling the user's request        User authentication to confirm that no unauthorized mobile device is used for the transaction; a PIN could preferably be used as an additional layer of user confirmation.The Requirement of Session in Commerce Usage        
Another key requirement of using SMS in commerce is that of the session. Often, when a web application sends out an outbound message to its users (e.g. campaign message like ‘all electronics 50% off if purchased in the next 6 hours’), the web application used expects the user to respond back in SMS to the corresponding outbound message within the specified time period. Typically, this requirement of session includes:                A request and response model mapping to outbound and inbound SMS messages;        A time out mechanism; and,        A Session Data sharing mechanism.        
One of the major shortcomings of using SMS messages in commerce application is the absence of syntax in SMS message, making its usage in commerce business processes difficult and impractical. Another major shortcoming is the lack of mapping of the SMS text to a predefined commerce business action or task. Often, SMS text maps to the type of commerce transaction to be carried out, usually the commerce business action requires additional parameters. Free form composing of 160 characters by human users makes impractical.
In addition, for SMS to be adopted in commerce application, there is a strong requirement for security mechanisms to provide user authentication; web application identification; receiving confirmation from SMS message recipients; and the ability to associate user responses with the intended commerce events.